package 设计模式;

/*
装饰器模式
装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。

这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。

我们通过下面的实例来演示装饰器模式的用法。其中，我们将把一个形状装饰上不同的颜色，同时又不改变形状类。

介绍
意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。

主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。

何时使用：在不想增加很多子类的情况下扩展类。

如何解决：将具体功能职责划分，同时继承装饰者模式。

关键代码： 1、Component 类充当抽象角色，不应该具体实现。 2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。

应用实例： 1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。 2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。

优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

缺点：多层装饰比较复杂。

使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销。

注意事项：可代替继承。

实现
我们将创建一个 Shape 接口和实现了 Shape 接口的实体类。然后我们创建一个实现了 Shape 接口的抽象装饰类 ShapeDecorator，并把 Shape 对象作为它的实例变量。

RedShapeDecorator 是实现了 ShapeDecorator 的实体类。

DecoratorPatternDemo 类使用 RedShapeDecorator 来装饰 Shape 对象。

装饰器模式的 UML 图
步骤 1
创建一个接口：
*/
/*
interface Shape { //抽象构件
   void draw();
}
//步骤 2
//创建实现接口的实体类。

class Rectangle implements Shape {//具体构件-->画矩形  定义一个接受附加责任(画矩形)的类
 
   @Override
   public void draw() {
      System.out.println("Shape: Rectangle");
   }
}
class Circle implements Shape {//具体构件-->画园形  定义一个接受附加责任(画园形)的类
 
   @Override
   public void draw() {
      System.out.println("Shape: Circle");
   }
}
//步骤 3
//创建实现了 Shape 接口的抽象装饰类。（亦可为非抽象类）
//
abstract class ShapeDecorator implements Shape {//装饰(Decorator)角色,持有一个抽象构件及实现抽象构件的方法
   protected Shape decoratedShape;
 
   public ShapeDecorator(Shape decoratedShape){
      this.decoratedShape = decoratedShape;
   }
 
   public void draw(){
      decoratedShape.draw();
   }  
}
//步骤 4
//创建扩展了 ShapeDecorator 类的实体装饰类。
//
class RedShapeDecorator extends ShapeDecorator {//具体装饰(ConcreteDecorator)角色
 
   public RedShapeDecorator(Shape decoratedShape) {
      super(decoratedShape);     
   }
 
   @Override
   public void draw() {
      decoratedShape.draw();         
      setRedBorder(decoratedShape);
   }
 
   private void setRedBorder(Shape decoratedShape){
      System.out.println("Border Color: Red");
   }
}
//步骤 5
//使用 RedShapeDecorator 来装饰 Shape 对象。
//
//public class DecoratorPatternDemo {
public class 装饰器模式 {
   public static void main(String[] args) {
 
      Shape circle = new Circle();
//      ShapeDecorator redCircle = new RedShapeDecorator(new Circle());
//      ShapeDecorator redRectangle = new RedShapeDecorator(new Rectangle());
      Shape redCircle = new RedShapeDecorator(new Circle());
      Shape redRectangle = new RedShapeDecorator(new Rectangle());
      System.out.println("Circle with normal border");
      circle.draw();
 
      System.out.println("\nCircle of red border");
      redCircle.draw();
 
      System.out.println("\nRectangle of red border");
      redRectangle.draw();
   }
}
*/
/*
步骤 6
执行程序，输出结果：

Circle with normal border
Shape: Circle

Circle of red border
Shape: Circle
Border Color: Red

Rectangle of red border
Shape: Rectangle
Border Color: Red
*/
/*
【定义】
装饰器模式又名包装(Wrapper)模式。装饰器模式以对客户端透明的方式拓展对象的功能，是继承关系的一种替代方案。

装饰器模式的结构
装饰器模式以对客户透明的方式动态的给一个对象附加上更多的责任。换言之，客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰器模式可以在不是用创造更多子类的情况下，将对象
的功能加以拓展。

【装饰器模式的类图如下：】

装饰器模式的类图
在装饰器模式中的角色有：

	-抽象构件(Component)角色：给出一个抽象接口，已规范准备接收附加责任的对象。
	-具体构件(ConcreteComponent)角色：定义一个将要接收附加责任的类
	-装饰(Decorator)角色：持有一个构件(Component)对象的实例，并定义一个与抽象构件接口一致的接口。
	-具体装饰(ConcreteDecorator)角色：负责给构件对象“贴上”附加的责任。

抽象构件角色

public interface Component {
    public void sampleOpreation();
}
具体构件角色：

public class ConcreteComponent implements Component {
    @Override
    public void sampleOpreation() {
        // TODO 完成相关的业务代码
    }
}
装饰角色

public class Decorator implements Component {
    private Component component;
    
    public Decorator(Component component) {
        this.component = component;
    }
    
    @Override
    public void sampleOpreation() {
        //委派给构件
        component.sampleOpreation();
    }

}
具体装饰角色

public class ConcreteDecoratorA extends Decorator {
    public ConcreteDecoratorA(Component component) {
        super(component);
    }
    
    @Override
    public void sampleOpreation() {
        super.sampleOpreation();
        //TODO 完成相关的业务代码
    }
}
public class ConcreteDecoratorB extends Decorator {
    public ConcreteDecoratorB(Component component) {
        super(component);
    }
    
    @Override
    public void sampleOpreation() {
        super.sampleOpreation();
        //TODO 完成相关的业务代码
    }
}
齐天大圣的例子
孙悟空有七十二般变化，他的没一种变化都给他带来一种附加的本领。他变成鱼儿时，就已到水里游泳；他变成鸟儿时，就可以在天上飞行。

本例中，Component的角色便是由大名鼎鼎的齐天大圣扮演；ConcreteComponent的角色属于大圣的本尊，就是猢狲本人；Decorator的角色由大圣的七十二变扮演。
而ConcreteDecorator的角色就是鱼儿、鸟儿等七十二般变化。

齐天大圣和七十二变的关系
示例代码
抽象构件角色“齐天大圣”接口，定义了一个move()方法，这是所有的具体构建类和装饰类必须实现的。

public interface TheGreatestSage {
    public void move();
}
具体构件角色“大圣本尊”，猢狲类

public class Monkey implements TheGreatestSage {
    @Override
    public void move() {
        System.out.println("Monkey move");
    }
}
抽象装饰角色“七十二变”

public class Change implements TheGreatestSage {
    private TheGreatestSage sage;
    
    public Change(TheGreatestSage sage) {
        this.sage = sage;
    }
    @Override
    public void move() {
        this.sage.move();
    }
}
具体装饰角色，“鱼儿”和“鸟儿”

public class Fish extends Change {
    public Fish(TheGreatestSage sage) {
        super(sage);
    }
    
    @Override
    public void move() {
        super.move();
        System.out.println("Change fish move");
    }
}
public class Bird extends Change {
    public Bird(TheGreatestSage sage) {
        super(sage);
    }
    
    @Override
    public void move() {
        super.move();
        System.out.println("Change bird move");
    }
}
客户端类

public class Client {
    public static void main(String[] args) {
        TheGreatestSage sage = new Monkey();
        //第一种写法
        TheGreatestSage bird = new Bird(sage);
        bird.move();
        
        //第二种写法
        TheGreatestSage fish = new Fish(new Bird(sage));
        fish.move();
    }
}
大圣本尊是ConcreteComponent类，而“鸟儿”、“鱼儿”是装饰类，要装饰的是大圣本尊，也就是猢狲类实例。

上面的例子中，系统把大圣从一直猢狲装饰成一只鸟儿（把鸟儿的功能加到了猢狲身上），然后又把鸟儿装饰成一条鱼儿（把鱼儿的功能装饰到猢狲+鸟儿身上），从而得到最终呈现猢狲+鸟儿+鱼儿
的结果。

【大圣装饰过程】
如上图所示，大圣的变化首先将鸟儿的功能附加到猢狲身上，然后又将鱼儿的功能附加到猢狲+鸟儿身上。

【装饰模式的简化】
大多数情况下，装饰模式的实现都要比上面的示意性例子要简单。

1.合并抽象构件和具体构件
如果只有一个ConcreteComponent类，那么可以考虑去掉抽象的Component类(接口)，把Decorator作为一个ConcreteComponent的子类。如下图所示：

ConcreteComponent --> Decorator(持有ConcreteComponent实例) --> ConcreteDecoratorA
                                                         --> ConcreteDecoratorB

2.合并装饰构件和具体装饰构件
如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。甚至在只有两
个ConcreteDecorator类的情况下，都可以这样做，如下图所示：

Component --> ConcreteComponent
          --> ConcreteDecorator(持有Component实例)


【透明性的要求】
装饰模式对客户端的透明性要求程序不要声明给一个ConcreteComponent类型的变量，而应当声明一个Component类型的变量。

用孙悟空的例子来说，必须永远把孙悟空的所有变化都当成孙悟空来对待，而如果吧孙悟空变成的鱼儿当成鱼儿，而不是孙悟空，那么就被孙悟空骗了，而这是不应当发生的。下面的做法是对的。

TheGreatestSage sage = new Monkey();
TheGreatestSage bird = new Bird(sage);
而下面的做法是不对的：

Monkey sage = new Monkey();
Bird bird = new Bird(sage);

【半透明的装饰模式】
然而，纯粹的装饰模式很难找到。装饰模式的用意是在不改变接口的前提下，增强所考虑的类的性能。在增强性能的时候，往往要建立新的公开的方法。即便是在孙大圣的系统里，也需要新的
方法。比如齐天大圣并没有飞行的能力，而鸟儿有。这就意味着鸟儿应该有一个新的fly()方法。再比如，齐天大圣并没有游泳的能力，而鱼儿有，着就意味着鱼儿应该有一个新的swim()方法。

这就导致了大多数的装饰模式的实现都是“半透明”的，而不是完全透明的。换而言之，允许装饰模式改变接口，增加新的方法。这意味着客户端可以声明ConcreteDecorator类型的变量，
从而可以调用ConcreteDecorator类中才有的方法：

TheGreatestSage sage = new Monkey();
Bird bird = new Bird(sage);
bird.fly();
半透明的装饰模式是介于装饰模式和适配器模式之间的。适配器模式的用意是改变所考虑的类的接口，也可以通过改写一个或几个方法，或增加新的方法来增强或改变所考虑的类的功能。大多数
的装饰模式实际上是半透明的装饰模式，这样的装饰模式也称作半装饰、半适配器模式。

【装饰模式的优点】
	1.装饰模式与继承关系的目的都是要拓展对象的功能，但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”一个需要的“装饰”，或者“除掉”一个不需要的“装饰”。
	  继承关系则不同，继承关系是静态的，它在系统运行前就决定了。
	2.通过不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出更多不同行为的组合。
【装饰模式的缺点】
	由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另外一方面，使用装饰模式会产生比使用继承关系所产生的更多的对象。
	而更多的对象会使得查找错误更为困难，特别是这些对象在看上去极为相似的时候。

【装饰设计模式在JAVA I/O库中的应用】
装饰模式在Java语言中最著名的应用莫过于JAVA I/O标准库的设计了。

由于JAVA I/O库需要很多性能的各种组合，如果这些性能都是用继承的方法实现的，那么每一种组合都需要一种类，这样就会造成大量性能重复的类出现。而如果采用装饰模式，那么类的
数目就会大大减少，性能的重复也可以减至最小。因此装饰模式是JAVA I/O�库的基本模式。

JAVA I/O库的对象结构如下图，由于JAVA I/O库的对象众多，因此只画出InputStream的部分。

InputStream结构图
根据上图可以看出：

-抽象构件角色(Component)：由InputStream扮演。这是一个抽象类，为各种子类型提供统一的接口。

-具体构件角色(ConcreteComponent)：由ByteArrayInputStream、FileInputStream、StringBufferInputStream等类扮演。它们实现了抽象构件角色所规定的接口。

-抽象装饰角色(Decorator)：由FilterInputStream、ObectInputStream等类扮演。它们实现了InputStream所规定的接口。

-具体装饰角色(ConcreteDecorator)：由几个类扮演，分别是BufferedInputStream、DataInputStream以及两个不常用到的
										类LineNumberInputStream、PushbackInputStream。

【半透明的装饰模式】
装饰模式和适配器模式都是“包装模式(Wrapper Pattern)”，它们都是通过封装其他的对象达到设计的目的的，但是它们的形态有很多区别。

理想的装饰模式在对被装饰的对象进行功能增强的同时，要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。而适配器模式则不然，一般而言，适配器模式并不要求对源对象的
功能进行增强，但是会改变源对象的接口，以便和目标接口相吻合。

装饰模式有透明和半透明两种，这两种的区别就在与装饰角色的接口与抽象构件角色的接口是否完全一致。透明的装饰模式也就时理想的装饰模式，要求具体构件角色、装饰角色的接口与抽象
构件角色的接口完全一致。相反，如果装饰角色的接口与抽象构件角色的接口不一致，也就说明装饰角色的接口比抽象构件角色的接口宽的话，装饰角色实际上已经成为了一个适配器角色，这
种装饰模式也是可以接受的，称为“半透明”的装饰模式，如下图所示：

在适配器模式里面，适配器模式的接口通常会与目标类的接口重叠，但往往并不完全相同。换句话说，适配类的接口会比被适配的目标类接口宽。

显然，半透明的装饰模式实际上处于适配器模式与装饰模式之间的灰色地带。如果装饰模式和适配器模式合并称为一个“包装模式”的话，那么半透明的装饰模式倒是可以成为这种合并后
的“包装模式“的代表。

【InputStream类型中的装饰模式】
InputStream类型中的装饰模式是半透明的。为了说明这一点，不妨看一看装饰模式的抽象构建角色InputStream抽象类的源代码。这个抽象类声明了九个方法，并给出了其中八个的实现，
另外一个是抽象方法(int read())，需要子类实现。

public abstract class InputStream implements Closeable {
    public abstract int read() throws IOException;
    
    public int read(byte b[]) throws IOException {
        return read(b, 0, b.length);
    }
    
    public int read(byte b[], int off, int len) throws IOException {
        //……
    }
    
    public long skip(long n) throws IOException {
        //……
    }
    
    public int available() throws IOException {
        //……
    }
    
    public void close() throws IOException {}
    
    public synchronized void mark(int readlimit) {}
    
    public synchronized void reset() throws IOException {
        throw new IOException("mark/reset not supported");
    }
    
    public boolean markSupported() {
        return false;
    }
}
下面是作为装饰模式的抽象装饰角色FilterInputStream类的源代码。可以看出，FilterInputStream的接口与InputStream的接口是完全一致的，也就是说，直到这一步，还是与
装饰模式相吻合的。

public class FilterInputStream extends InputStream {
    public int read() throws IOException {
        return in.read();
    }
    
    public int read(byte b[]) throws IOException {
        return read(b, 0, b.length);
    }
    
    public int read(byte b[]) throws IOException {
        return read(b, 0, b.length);
    }
    
    public long skip(long n) throws IOException {
        return in.skip(n);
    }
    
    public int available() throws IOException {
        return in.available();
    }
    
    public void close() throws IOException {
        in.close();
    }
    
    public synchronized void mark(int readlimit) {
        in.mark(readlimit);
    }
    
    public synchronized void reset() throws IOException {
        in.reset();
    }
    
    public boolean markSupported() {
        return in.markSupported();
    }
}
下面是具体装饰角色PushbackInputStream的源代码：

public class PushbackInputStream extends FilterInputStream {
    private void ensureOpen() throws IOException {
        if (in == null)
            throw new IOException("Stream closed");
    }
    
    public int read() throws IOException {
        //……
    }
    
    public int read(byte[] b, int off, int len) throws IOException {
        //……
    }
    
    public void unread(int b) throws IOException {
        //……
    }
    
    public void unread(byte[] b, int off, int len) throws IOException {
        //……
    }
    
    public void unread(byte[] b) throws IOException {
        unread(b, 0, b.length);
    }
    
    public int available() throws IOException {
        //……
    }
    
    public long skip(long n) throws IOException {
        //……
    }
    
    public boolean markSupported() {
        return false;
    }
    
    public synchronized void mark(int readlimit) {
    }
    
    public synchronized void reset() throws IOException {
        throw new IOException("mark/reset not supported");
    }
    
    public synchronized void close() throws IOException {
        //……
    }
}
通过查看源代码，你会发现，这个装饰类提供了额外的方法unread()，这就意味着PushbackInputStream是一个半透明的装饰类。换句话说，它破坏了理想的装饰模式的要求。如果客户端持有一个类型为InputStream对象的引用in的话，那么如果in的真实类型是PushbackInputStream的话，只要客户端不需要使用unread()方法，那么客户端一般没有问题。但是如果客户端必须使用这个方法，就必须进行向下类型转换。将in的类型转换成为PushbackInputStream之后才可能调用这个方法。但是，这个类型转换意味着客户端必须知道它拿到的引用是指向一个类型为PushbackInputStream的对象。这就破坏了使用装饰模式的原始用意。

现实世界与理论总归是有一段差距的。纯粹的装饰模式在真实的系统中很难找到。一般所遇到的，都是这种半透明的装饰模式。

示例程序
下面是使用I/O流读取文件内容的简单示例
*/
import java.io.BufferedInputStream;
import java.io.DataInputStream;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;

//public class InputStreamTest {
public class 装饰器模式 {
    public static void main(String[] args) {
        DataInputStream dis = null;
        try {
            dis = new DataInputStream(new BufferedInputStream(new FileInputStream("23.txt")));
            //抽象构件：InputStream
            //具体构件：FileInputStream
            //抽象装饰：FilterInputStream
            //具体装饰：BufferedInputStream、DataInputStream
            byte[] bytes = new byte[dis.available()];
            System.out.print(dis.available());
            dis.read(bytes);
            String content = new String(bytes);
            System.out.println(content);
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            try {
                dis.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}
//						┌─────────────┐
//						│ InputStream │ ←-抽象构件
//						└─────────────┘
//							    ▲ ▲
//┌────────────────────┐ │ │ ┌─────────────────┐
//│  FileInputStream   │─┤ └─│FilterInputStream│ ←--抽象装饰角色
//└────────────────────┘ │   └─────────────────┘
//┌────────────────────┐ │     ▲ ┌───────────────────┐
//│ByteArrayInputStream│─┤     ├─│BufferedInputStream│
//└────────────────────┘ │     │ └───────────────────┘
//┌────────────────────┐ │     │ ┌───────────────────┐
//│ ServletInputStream │─┘     ├─│  DataInputStream  │
//└────────────────────┘       │ └───────────────────┘
//          						 │ ┌───────────────────┐
//          						 └─│CheckedInputStream │
//			↑                      	└───────────────────┘
//			|                               ↑
//		具体构件                         具体装饰角色 
/*
观察上面的代码，会发现最里层是一个FileInputStream对象，然后把它传递给一个BufferedInputStream对象，经过BufferedInputStream对象处理后，再将处理后的对象传递
给DataInputStream对象进行处理。这个过程，其实就是装饰器的组装过程，FileInputStream对象相当于原始的被装饰的对象，而BufferedInputStream对象
和DataInputStream对象则相当于装饰器。
*/